Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Building a TCP/IP Router-Based Network

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Putting Together the Sample Internetwork
In this section, I will pull together the various sections of this chapter to illustrate how the concepts presented can be integrated to build an internetwork. The requirements of each and every individual internetwork vary considerably. It is unlikely that the design I present here will be the optimal one for your internetwork; however, it does present a reasonable base from which to start. Unlike in other chapters, where I have tried to be objective, in this section I have to be opinionated, because without a specific problem to solve with documented evidence, there are only opinions.
Where applicable, I will highlight tradeoffs made and areas where the design presented will run into problems under certain types of traffic loads. Additionally, most of what I say is based on my practical experience and therefore cannot be taken as statistically significant, as I am only one engineer among thousands. Having suitably qualified the statements I am about to make, in an attempt to save my home and family from those who hold views different from mine, I shall press on.
Defining the Problem
As mentioned at the outset of this chapter, we have an organization headquartered in Chicago, with concentrations of branches around New York, Atlanta, Dallas, Los Angeles, and San Francisco. All hosts are located in Chicago, with local Windows NT servers in each remote site for delivering file and print services. The internetwork must deliver host access, Internet, e-mail, and remote dial access to all users. Here are the design decisions I have made:
  1. The Windows NT servers in each branch will use TCP/IP for WAN communications, utilizing a centralized WINS server located in Chicago for name resolution.
  2. Dial-up services for users operating outside their branch will be provided centrally via a pool of asynchronous interfaces located in Chicago. Users then access their branch-based NT servers over the WAN. To dial the asynchronous interfaces in Chicago, the users dial an 800 number.
  3. The backbone will rely on multiple links between distribution centers rather than on dial backups for redundancy.
  4. Branch routers will use ISDN to establish a dial backup connection in the event that their link to their distribution center (New York, Atlanta, Los Angeles, etc.) goes down. The ISDN link will be made back to the central location in Chicago.
  5. The whole internetwork will be based on one of the IANA-reserved Class B addresses and connected to the Internet via a PIX firewall located in Chicago.
  6. HSRP will not be used at the Chicago location, so we will have to think about how to protect host access from being lost by one router failing.
  7. I will use individual leased lines rather than a commercial frame relay service.
  8. I will use Cisco HDLC rather than PPP for the encapsulation on the point-to-point WAN links.
Let's see if I can justify my reasons for setting things up this way. First of all, let's tackle the idea of distributed rather than centralized Windows NT servers. Some high-level managers I know like the idea of centralizing servers for ease of administration and point out that workstation-to-server communications can be achieved over a WAN link as easily as over a LAN link. This is true, and I can set up a workstation to access a server over a WAN link and it will work well. The issue I take with this scheme is with how well it scales as the network grows. Basically, it does not. The more workstations you add, the more traffic the WAN link has to support—not only requests for file services, but announcements, advertisements, and other overhead generated by network operating systems grow as the number of workstations grow.
Next, let's discuss providing Internet services from the central location. This is enough to give a network administrator a heart attack on the spot. Just think: All those graphics, audio files, searches, and so forth taking up valuable WAN bandwidth. I agree that providing Internet services over your own WAN bandwidth when the Internet already has bandwidth available in the branch office locations may seem like a waste. I believe, however, that connecting your internetwork to the Internet is one of the prime security risks you run.
My opinion is that allocating lower priority to Internet traffic over the WAN and feeling good about secure centralized Internet access is a good tradeoff.  Additionally, there are technical problems involved in providing one router to a remote site to access the corporate WAN and another to access the Internet. PCs can define only one router as the default, either the WAN or the Internet router. Therefore, providing Internet access at remote locations requires a more complex router, one that probably has a proxy server to connect to the Internet. This becomes costly.
So what about the backbone having multiple routes between distribution centers, and no dial backup for these links? This is easy: As the backbone links grow in capacity, they become more and more difficult to back up with dial links. With a sensible backbone configuration, you can design in enough redundancy for your needs. T-1 and fractional T-1 services are reliable these days, and if you experience specific problems, additional links can be added piecemeal to improve redundancy.
A big point of contention for many business managers is justifying the potential additional costs of individual leased lines compared to subscription to a public frame relay network. The arguments I gave in the frame relay section still hold. Frame relay networks were good when first put together, when utilization was low, because you could subscribe to a low CIR and get substantially more throughput on average. Now that vendors' frame relay networks are more fully subscribed, that "free" bandwidth is not available and performance over these networks is not what it was. In some cases, the need to specify a CIR approaching what you would need on a leased-line basis approaches the cost of having your own dedicated bandwidth. I also like having control of how my network traffic gets from source to destination, not to mention that since these frame relay networks are public, you face additional security risks that you don't encounter with your own leased lines.
Next, why have dial-up users dial the central location and access local files over the WAN instead of having them dial the branch location? In this case, the argument to provide a central rather than distributed resource wins out. With a central dial-up pool, you can set up an 800 number service and get a lower rate for users calling long-distance to access their data. While users will be using WAN bandwidth to access NT server files, they will not be using WAN bandwidth to access host applications or the Internet, so I think it’s a wash. (I would not allow any application to be downloaded over a dial-up link, however; all applications need to be loaded on the hard drives of the computers being used for dial-up connections.)
I feel confident that I will have full backing in this judgment from anyone who has tried to remotely support an asynchronous communications server, modem, and telephone line. A central pool of ports that can be tested, one in which bad ports can be busied out and components easily replaced, is a significantly smaller headache than distributed facilities. Some branch managers argue that when they go home and want to dial in, it is a local call to the office, so why do they have to dial an 800 number and incur expense for the company? This may be true, but I believe that most calls will be made by users traveling on business and would be long-distance phone calls anyway. I’ll stick with a central dial pool on both technical and cost grounds.
Next, let’s talk about using Cisco HDLC rather than PPP for the point-to-point links on the internetwork. PPP offers the opportunity for CHAP authentication, which HDLC does not, and is a more modern protocol with generally more configuration options. The deciding factor for me, though, is that with Cisco HDLC, you can put a CSU/DSU device in loopback, and if the connection between the router port and the CSU/DSU is good, the line protocol will come up. With PPP it will not. This is a good starting point to have when you are trying to troubleshoot, particularly an initial line installation. If, however, you choose to utilize any LAN extender devices, you will have to use PPP. I will choose PPP for the asynchronous links, as the improved security features of this protocol make it the obvious choice for a potential security loophole such as dial-up connections.
Now we will discuss having the remote site routers use ISDN to dial the central location in Chicago, rather than their distribution center, in the event of a line failure. This has many implications, not the least of which is how you choose to implement your IP addressing scheme. The first point to consider is what IP address the interface on the branch router will have for dialing in to a central pool. It’s not feasible for these interfaces to have their own IP addresses.
Think about what happens when the ISDN connection to the backup pool is made. Normally a router interface will expect the directly connected devices to be addressed on the same subnet as itself. In addition, a subnet on a properly designed internetwork will appear at only one location. So what subnet does the backup pool use? This cannot be resolved if you assign specific addresses to the backup pool, as you will never know which subnet from the field will be trying to dial in. So both the serial interface used for ISDN dial backup and the interfaces in the central location dial backup pool must use IP unnumbered.
Next, should we implement one Class B network number with subnets, or allocate one network number for the backbone and different network numbers for the distribution and branch connections? The latter option reduces the size of the routing tables in the backbone routers, and hence reduces the size of routing updates. The reason is that network numbers are summarized into one route at the boundary between major network numbers. This means that a network number that is broken up into multiple subnets in the distribution center will only have one entry in the routing table of the backbone router. As we have chosen to have branch routers connect to the central location in Chicago, however, we cannot implement an addressing scheme with one network number for the backbone and separate network numbers for the distribution centers.
Figure 7-23 illustrates one way to interconnect sites in our sample WAN.
Figure 7-23: Illustration of how the sample network could be connected and addressed
With just one network number and multiple subnets, the routing tables (and hence the size of routing updates) grow as the number of branches grows. This can be a problem for branches connected on dial backup, as large routing updates can consume significant bandwidth. If the internetwork grows to the point that it's servicing more than 1000 branches, you might be forced to implement a distributed dial backup scheme. An option we will consider is using access lists applied as distribution lists to restrict the size of routing advertisements sent on low bandwidth links.
With a central dial backup pool of ports, we will implement one network number for the entire internetwork and choose an appropriate netmask for all interfaces. I could choose a netmask of 255.255.255.224. This gives 30 usable addresses for each location and 2046 subnets. If a location has more workstations than that, a secondary address can be used to give another 30 usable addresses from a different subnet. If, in our sample internetwork, most of the sites have more than 30 workstations, we can assign a netmask of 255.255.255.192 for all interfaces, which gives us 62 usable addresses for each subnet, with 1022 subnets. Let's use 255.255.255.192, as this company cannot imagine having more than 1000 locations, and having more usable addresses in the subnet makes it easier if a few branches are larger than 30 workstations.
The Central Site Configuration
This is where all the hosts and access points for the Internet, as well as the pool of ISDN ports used for dial backup connections, are located. When putting together an internetwork of this type, I would go to great pains to ensure that access to the hosts is via the TCP/IP protocols. Most hosts support TCP/IP directly and allow remote client computers to connect via Telnet, and even IBM hosts have capabilities for this through TN3270 and TN5250. An emerging technology—software loaded on the host that allows hosts to be accessed via HTTP and display host information in a WWW format—also is a possibility. As long as we restrict our WAN to using TCP/IP, however, we are in good shape whichever way we go.
The next big decision is how to connect the central site LAN to the WAN. We have said that HSRP will not be used in this instance, and why not? Well, HSRP is a really good idea if both of the routers that are sharing the responsibility of servicing traffic sent to the phantom have equally good routes to all destinations. This is not the case in our internetwork, so let's look at what would happen if we were to implement HSRP here.
An HSRP configuration has two routers, one of which will be elected to service traffic sent to the phantom. In our internetwork, we may choose to connect San Francisco and Los Angeles to one router, and New York and Atlanta to the other. This configuration would enable traffic to get to all distribution centers even if one of the HSRP routers failed. Let's look at what happens during normal operation.
Say the router connected to San Francisco and Los Angeles is elected as the primary and will then service all requests sent to the phantom. Traffic bound for New York and Atlanta, therefore, will be sent to Los Angeles first and the direct links to New York and Atlanta will not be used. The only time they would be used is if the router connected to San Francisco and Los Angeles failed. Clearly this is far from an optimal situation. In this case I recommend a low-tech solution: Have an identically configured standby WAN 4700 router in the same cabinet as the live one, and manually swap over connections if it fails.
If you need the resilience that HSRP offers, then you need to put together a more complex set of WAN interconnections, something like that shown in Fig. 7-24. This configuration has each router in the HSRP pair with the same WAN connections; it does not matter so much which router gets elected as the master and routes all the traffic bound for the HSRP phantom. As you can see, HSRP gets expensive on WAN bandwidth and the lines connected to the inactive HSRP router do not carry any traffic. Given that Cisco hardware really is reliable, in this situation I would stick with the manual swap-over option.
Figure 7-24: WAN interconnectivity of HSRP implementation
Finally, for the central site, we should mention that a separate LAN has been set aside for the network management station. This is so we can tell all the routers out in the field to accept SNMP commands only from this LAN. The final configuration for the central location in Chicago is given in Fig. 7-25.
Figure 7-25: Central location network configuration
Distribution Center Configuration
The distribution center configuration is fairly simple. Each distribution center router will have serial port connections to the backbone and serial port connections to the individual branches. There are no Ethernet connections because no servers are located at the distribution center in this design, and no ISDN connections because the branches dial back to the central location if a local loop fails.
The issues related to managing the distribution routers are more procedural than technical. First, will the distribution center router be located in a branch, or in a communication vendor's facility? The advantage to it being located with other communications equipment in a vendor's facility is that it will be in a secured room, probably one with air-conditioning, uninterruptible power supply, and maybe even a backup generator. This might be costly, however, and most of the vendor's facilities are not staffed; if the router needs rebooting, or it fails and needs to be replaced, the distribution center will be out of action until someone can make the trip there to do the necessary work.
Remote Site Configuration
Here I choose to give the Serial 0 port a fixed IP address and use IP unnumbered for the ISDN backup. I have covered why we use IP unnumbered for the ISDN backup port, but why don't we use it for the primary connection? The section on upgrading IOS for 2500-series routers gives us the answer. Operating from the Rxboot program, IP unnumbered is not supported. It is simpler to assign an IP address for the port that will be used during the upgrade process than to change the IP configuration just for the upgrade.
The next question is why use an ISDN terminal adapter instead of a built-in BRI? In the internetwork as it stands, using a built-in BRI probably makes more sense. Let's look to the future, however. Many businesses, as they grow and their dependency on technology gets more significant, look to developing a disaster recovery plan. Typically a disaster recovery site will be built. Let's consider what happens if the central site burns down and operations need to be run from the disaster recovery site.
All the distribution centers are hard-wired to the primary location, so what we need to achieve is the ability for all branches to dial into the disaster recovery site. Under normal conditions, the ISDN dial port is configured to dial the original central location. If that location has burned down, there is no way to Telnet to the branch routers and change the dial string so that they dial to the backup site. If you have a terminal adapter, however, you can instruct branch personnel to change the ISDN numbers dialed through the front panel of the terminal adapter and pull out the primary connection in the branch router's Serial 0 port. You now have a means of connecting branches to your disaster recovery site fairly quickly, albeit with some manual intervention. The remote site configuration discussed here is illustrated in Fig. 7-26.
Figure 7-26: Remote site network configuration
ISDN Backup and Asynchronous Dial-Up Service Configuration
Chapter 6 gives detailed configuration for the router that is to provide the ISDN backup pool and we will not repeat that discussion here. Configuration of asynchronous communications also has been discussed in Chap. 6, under the section on PPP communications. The key points for configuring an asynchronous routed interface are:
  IP addresses are assigned to a computer at connect time, a step that simplifies providing the ability for any computer to connect to any port.
  CHAP authentication is in place and managed by a TACACS server that logs what user logged in, when, and for how long.
Miscellaneous Issues
There are many miscellaneous issues to consider when assembling an internetwork of this kind. The first, and probably most important, is the type of routing protocol to implement. My choice is among a distance vector protocol such as IGRP, a link state protocol such as OSPF, or a hybrid like EIGRP. Link state protocols scale well and have many attractive features, but I think they are overly complex to optimize and deploy. If you choose to devote your life to becoming expert in link state routing protocol implementation, you will always have work; however, I seem to find better things to do with my time.
For the type of internetwork we are talking about here, Fast IGRP or EIGRP are perfectly adequate. IGRP has been around longer and therefore is very stable. EIGRP has become more stable in recent times and is ready for deployment in large internetworks. I have a slight preference for EIGRP at this stage. An important part of taking advantage of the enhanced facilities of modern routing protocols is defining the correct bandwidth in the configuration of each serial interface used. This is imperative, as it ensures that the most appropriate metric is calculated for each route. If a bandwidth command is not implemented on each interface, the default of T-1 bandwidth is assumed for the purposes of metric calculations, and suboptimal route selection results.
With the design presented, it is possible to have only one LAN interface on each host and NT server and have everyone delegate routing responsibilities to a router, by use of the default gateway command in each host and server. I like this way of doing things. Cisco routers are much better routers than any host or server. Servers and hosts should do what they do best: serve applications, file, and print services to users, and authenticate usernames. Routing should be left to the specialist router devices.
The next issue to consider is how to get to know your internetwork once it is operational. Despite advances in network management in recent years, there is still no real substitute for a network administrator knowing how the internetwork operates under normal conditions and being able to spot trends and abnormal activity. “Abnormal activity” might mean an intruder or a new application behaving inefficiently. In many cases, the only way to know what is at fault is to know in some detail how the internetwork performs when all is well. So what should be monitored? Here is a short list of generic criteria, which you probably will add to for your specific situation, but this list is a good start. We will cover these measurements again in Chap. 8, from a troubleshooting perspective.
The show interface command (discussed in more detail in Chap. 8) should become a good friend. It will give you the following information very easily for each interface you want to examine:
  Current throughput, presented as a 5-minute average: There may be times when you want to know the throughput over a shorter time span. Unfortunately, you cannot do this with a Cisco router; you need a network analyzer of some type to get this information.
  Number of packets dropped by the router: Typically a router will drop a packet if its buffers are full, or the hold-queue value (which is the number of packets allowed to be outstanding for a particular interface) is exceeded.
It is also worth knowing how many carrier transitions are normal for the lines used on your internetwork. This normally should be a low number, as it represents how many times the leased line supplied by the telephone company went down and came back up again.
In addition, the show buffers command presents useful information. This display (again, discussed in more detail in Chap. 8) shows the different sizes of buffers, their utilization, and whether you are running out of buffers of a specific size on a regular basis.
The show proc and show proc mem commands help you keep track of processor and memory utilization, which should not be subject to large changes. You can collect these values either manually or regularly via SNMP from a management station. If you can keep track of all these variables, you should be in a good position to determine what has caused a problem when it arrives—and problems always come along for an internetwork. It’s part of life.

 


 
Books24x7.com, Inc © 2000 –  Feedback